oli-obk is not on the review rotation at the moment.
They may take a while to respond.

@bors r+

📌 Commit 2784327 has been approved by oli-obk

It is now in the queue for this repository.

@bors rollup

Does anyone read the tracking issues any more?

Whatever. I explicitly had this as part of #144289 and was not including it because the other reviewer, @tgross35, expressed apprehension about adding heap-allocated trait impls at the end. Part of this PR exists as #145279, which you would find out if you read the comments on the tracking issue you linked.

@bors r-

@oli-obk @clarfonthey @tgross35 I don't think this PR should have been rejected. Cow is often used to bridge cases where allocation may or may not occur. When it doesn't, we don't want to force non-const on the developer. With these const From traits, you can effectively use Cow in generic contents where the conditionality of the const depends on the implementor. For example:

const trait Textify<'a> {
    type TextType: [const] Into<Cow<'a, str>>;
    
    fn text(&self) -> Self::TextType;
}

In this case, the implementor can choose const or not based upon the implementation of text().

Another simpler case is where conditional compilation is used. Here's a somewhat contrived example:

#[cfg(feature = "alloc")]
type Text<'a> = alloc::borrow::Cow<'a, str>;

#[cfg(not(feature = "alloc"))]
type Text<'a> = &'a str;

const fn decode<'a>(bytes: &'a [u8]) -> Text<'a> {
    core::str::from_utf8(bytes).unwrap().into() // Cow needs a const From impl here.
}

The key point is that without the impl const From for Cow, you'd have to conditionally compile at every site where Text is constructed.

These implementations will absolutely wind up const eventually; there isn't any issue there. The problem is that const traits are not yet through RFC and stable, and we want to keep the surface area reasonably minimal until they are stable. These are indeed trivial implementations, but alloc is an easy cutoff point; anything alloc/std is going to be a "nice to have" implementation, rather than something fundamentally blocking the ability to experiment with const traits.

We do not have an official policy here (I've been meaning to write a proposal) so it's possible the others feel differently, but I would still prefer to wait until const traits are stable for implementations like this. There isn't any rush.

See also #t-compiler/const-eval > SystemTime regression #146228

These implementations will absolutely wind up const eventually; there isn't any issue there. The problem is that const traits are not yet through RFC and stable, and we want to keep the surface area reasonably minimal until they are stable. These are indeed trivial implementations, but alloc is an easy cutoff point; anything alloc/std is going to be a "nice to have" implementation, rather than something fundamentally blocking the ability to experiment with const traits.

We do not have an official policy here (I've been meaning to write a proposal) so it's possible the others feel differently, but I would still prefer to wait until const traits are stable for implementations like this. There isn't any rush.

See also #t-compiler/const-eval > SystemTime regression #146228

➜  rust git:(master) $ egrep -R '(const_convert|const_default)' library/alloc
library/alloc/src/lib.rs:#![feature(const_convert)]
library/alloc/src/lib.rs:#![feature(const_default)]
library/alloc/src/borrow.rs:#[rustc_const_unstable(feature = "const_convert", issue = "143773")]
library/alloc/src/borrow.rs:#[rustc_const_unstable(feature = "const_convert", issue = "143773")]
library/alloc/src/borrow.rs:#[rustc_const_unstable(feature = "const_convert", issue = "143773")]
library/alloc/src/vec/mod.rs:#[rustc_const_unstable(feature = "const_default", issue = "143894")]
library/alloc/src/string.rs:#[rustc_const_unstable(feature = "const_default", issue = "143894")]
library/alloc/src/collections/mod.rs:#[rustc_const_unstable(feature = "const_convert", issue = "143773")]
library/alloc/src/collections/mod.rs:#[rustc_const_unstable(feature = "const_convert", issue = "143773")]

@tgross35 There are already const implementations in alloc. Drawing the line at this PR feels rather arbitrary.

In retrospect I should have requested them dropped from #145279. I don't think there is any need to remove them at this time, given they aren't particularly invasive, but I don't think it should serve as a precedent for adding more.

Again, others may feel differently and we don't yet have a policy. And the incremental change isn't much. But I really don't think anybody's const experimentation is blocked on wrappers around Cow::Borrow/Cow::Owned, both of which already work perfectly fine in const today.

@tgross35 But I really don't think anybody's const experimentation...

Mine is. That's why I wrote the patch.